Rather than storing and managing 'null' string in cookies, we can choose not to store any null values.

If we update writeCookie method as follow, no null or empty string will be written.

 writeCookie: (name, value) ->
    if !!value
       @createCookie name, value, @_cookieExpiryDays, null, @_domain, @_secure
    return

In this way the initial parameters and the new feature reset_params_at_session_end will not work, breaking also the release 1.2.0.

Can you please elaborate why won't those work? Also, in what ways does it break 1.2.0 release? I'm sorry, I'm a bit confused here.

I am hesitant to store 'null' strings in cookie and then ignore them while reading. It creates more cruft that need to be kept track of.

The initial_utm_params and additional_initial_params_map are based on the writeCookieOnce method that checks for cookie existence before writing it.

Yes, if nothing is written, nothing will be read.

To be honest, I'm having a hard time following these changes which is a bad sign for something that's supposed to be simple. Perhaps I'm not thinking straight and need to revisit these when I have more spare time. Since you have your own fork, this doesn't block you from using these changes for your own use.

This is super simple. As i said some methods are based on the writeCookieOnce one. This method will try to read the cookie before writing it. So if we don't write anything in the cookie it will always write the cookie. So we must store null, 0 or something in the cookie to keep the blank values, like in initial_utm_params.

If you don't want to store null values in the cookies then another way could be to use the visits counter and the current section cookie to "know" when the writeCookieOnce method should and should not write the cookie.

Let me know what you prefer. As i said, i have some spare time to do the job, no problem.